-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Fix working directory of simple file-based apps #51828
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: release/10.0.2xx
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR fixes the working directory behavior for simple file-based apps (.cs files run directly without a project file) to make it consistent with project-based apps. Previously, file-based apps always had their working directory set to the directory containing the source file, ignoring the process's current working directory.
- Removes hardcoded working directory override in
CreateCommandForCscBuiltProgram - Adds comprehensive tests verifying working directory behavior across different build levels (CSC-only, MSBuild, none)
- Verifies that
AppContext.GetData("EntryPointFileDirectoryPath")still correctly returns the entry point file's directory
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/Cli/dotnet/Commands/Run/RunCommand.cs | Removes .WorkingDirectory(Path.GetDirectoryName(entryPointFileFullPath)) from CreateCommandForCscBuiltProgram to allow working directory to default to current directory instead of being hardcoded to the entry point file's directory |
| test/dotnet.Tests/CommandTests/Run/RunFileTests.cs | Adds two new test methods (WorkingDirectory and WorkingDirectory_CscOnly_AfterMSBuild) and updates the Build helper method to support custom working directory testing |
| var commandSpec = new CommandSpec(path: exePath, args: ArgumentEscaper.EscapeAndConcatenateArgArrayForProcessStart(args)); | ||
| var command = CommandFactoryUsingResolver.Create(commandSpec) | ||
| .WorkingDirectory(Path.GetDirectoryName(entryPointFileFullPath)); | ||
| var command = CommandFactoryUsingResolver.Create(commandSpec); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like removing the WorkingDirectory call just causes the ordinary logic for deciding the working directory of a command to take over? Is that right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, basically it remains null which means "current directory". In the case of the simple CSC-only optimized build path, there is no way to override that, which is fine. It can only be overridden via MSBuild property but that wouldn't hit the optimized CSC-only path.
Fixes #51778.